home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group97a.txt / 000083_icon-group-sender _Thu Mar 13 14:53:19 1997.msg < prev    next >
Internet Message Format  |  2000-09-20  |  5KB
  1. Received: by cheltenham.cs.arizona.edu; Fri, 14 Mar 1997 10:40:05 MST
  2. To: icon-group@cs.arizona.edu
  3. Date: Thu, 13 Mar 1997 14:53:19 -0500
  4. From: Jan Galkowski <jan@digicomp.com>
  5. Message-Id: <33285B2F.41C67EA6@digicomp.com>
  6. Organization: Digicomp Research Corporation
  7. Sender: icon-group-request@cs.arizona.edu
  8. References: <Pine.SGI.3.95.970305103012.2721A-100000@shellx.best.com>, <01bc2d80$5cac97d0$5f030514@dschauma>
  9. Subject: Re: Recursive directory traversal in Icon
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11. Status: RO
  12. Content-Length: 4485
  13.  
  14. Dave Schaumann wrote:
  15. > 
  16. > Brian Rogoff <bpr@best.com> wrote in article
  17. > <Pine.SGI.3.95.970305103012.2721A-100000@shellx.best.com>...
  18. > > Hi,
  19. > >       I've been reading the Icon web references, trying to decide if I
  20. > > should forsake Perl in favor of Icon, and I have two questions.
  21. > >
  22.  
  23. [snip]
  24.  
  25. > > (2) Why no module system?
  26.  
  27.  While it speculating on intent may be interesting, it's usually a waste
  28.  of time.  Better, IMO, is looking at the product and seeing what it has
  29.  and provides and what it doesn't.  A "module system" is essentially a
  30.  device for managing globs of text, naming them, and performing controlled
  31.  substitutions upon them.  (I don't mean "glob" in any Unix-ish or Perl-ish
  32.  sense.)  To only slightly exaggerate, there's nothing in any "module
  33.  system" which can't be modelled in a proper implementation of the lambda
  34.  calculus, e.g., in SCHEME.  So, one possible explanation is that a 
  35.  "module system" is in some important sense excess baggage.
  36.  
  37.  [The idea of using the lambda calculus for a "macro level language" isn't
  38.  original--  Peter Henderson and a coworker documented such a system for
  39.  reconstructing a very large and old FORTRAN program someplace in 
  40.  _Software: Practise and Experience_ in the mid-'80s.]
  41.  
  42. > 
  43. > I can't answer this directly.  However, there is Idol, which has been
  44. > described
  45. > as "Object Oriented Icon".  That's pretty much all I know about it, so I
  46. > don't
  47. > know if it supports modules.  I assume that "Object Oriented" means
  48. > inheritence,
  49. > which means classes, which means some form of encapsulation/data hiding...
  50. > 
  51. > I agree with your point, though.  Another big weakness of Icon is that
  52. > there's
  53. > just too much stuff that goes in the global name space.
  54. > 
  55.  
  56. With Icon's power and support of functions and procedures as first-class
  57. objects, I wonder whether when we all -- and I very much include myself --
  58. feel the pressure for adding more to Icon, we just aren't being 
  59. imaginative enough in using the tool we're given.  Yes, we're products of
  60. a community of programming artists and so fads and traditions weigh
  61. heavily upon our practice.  But Icon isn't a run-of-the-mill language
  62. by any means, and it is freed of many of the constraints which the usual
  63. languages are.  C.A.R.Hoare (I believe) once wrote a position paper on
  64. the then-evolving programming language Ada entitled "Generalzing Ada
  65. by removing limitations".
  66.  
  67. I'm investing in this post so heavily because I am on a search for such
  68. a means of expression which is strictly supported by the existing
  69. Version 9.3 of Icon, yet addresses some of these concerns regarding
  70. big programs and modules and all that.  In fact, one of my reasons
  71. for asking after people's "biggest Icon programs" was to see how far
  72. people had carried Icon itself.
  73.  
  74. One could, for example, without that much effort and _without_ 
  75. clobbering the problem by using excessive string invocation, imitate
  76. all the packaging and generic facilities of Ada95, leaving aside
  77. Ada's tasking facilities for the moment. (They could be modelled,
  78. too, but that discussion, I believe, degenerates into one over
  79. what constitutes an adequate simulation of asychronicity.)
  80.  
  81. Similarly, there really is no compelling reason to include events 
  82. and event-handlers in Icon simply because one has popular languages
  83. like Tcl/Tk, Visual Basic, etc., which offer built-in events and 
  84. support a certain style of GUI programming.  In the small, one can 
  85. imitate these facilities and in the large I really think that style
  86. of GUI design deserves challenging: Not all applications are Web
  87. pages, after all, and introducing problems of synchronization
  88. and data sharing in contexts which really doesn't need them
  89. hardly seems like progress.  Besudes, at some level, Tcl/Tk and
  90. Visual Basic embody a polling loop in their design, even if it
  91. is a machine interrupt handler.  At least Icon provides an
  92. explicit one.
  93.  
  94. I'm sorry for going on so long, but I invite people to challenge
  95. themselves to think how clear and neat expressions of what they
  96. might want in this area could be expressed in the _existing_
  97. Icon language.  This isn't because the Icon definition would
  98. be that hard to change, but because IMO programming languages
  99. are supposed to be tools to think with creatively, not be simply
  100. a sugar-coated subroutine library.
  101.  
  102. > -Dave
  103.  
  104. -- 
  105.  Jan Theodore Galkowski, 
  106.  developer, tool & numerical methods elf
  107.    Digicomp Research Corporation,
  108.    Ithaca, NY 14850-5720
  109.  jan@digicomp.com 
  110.  (also jtgalkowski@worldnet.att.net)
  111.